Coding JavaScript for Mobile Browsers (part 11)

5.4. Focusable and form events

Table 27 shows support for the onfocus, onblur, onchange, and onsubmit (only for forms) events on different mobile browsers.

5.5. Over events

The over events include mouseover and mouseout and are typically used for creating a hover effect when the cursor is over an element. Usage of these events in mobile websites is discouraged for must-have features, because they will only work on cursor-based browsers. Touch and focus devices don’t have an “over” state; it should be replaced by an active state or a focus one for focus-based browsers.

Note:

Safari on iOS also supports the onmousewheel event when the user is scrolling the element using two fingers at the same time.

5.6. Resizing, scrolling, and orientation change events

When the user activates scrolling over the document, some browsers fire the onscroll event from the document as a whole. Others also support the onresize event, which fires when the window size is changed. Users cannot resize mobile browser windows in the way they can resize desktop application windows, but a resize can be generated if the orientation of the device changes from portrait to landscape or vice versa.

Note:

Using percentage values for widths is a good mobile design practice. It automatically works on all devices and allows your application to readapt automatically to any orientation. Unfortunately, some devices (like the Nokia N70) have some bugs with percentage values so the block still wraps around content, creating an awful horizontal scroll.

As of iOS 2.0, Safari also offers the onorientationchange window event and an orientation property. This property has a value of 0 in portrait mode, 90 in landscape mode, and −90 in inverse landscape mode. We can use this to make changes in the DOM or use the body class pattern to change the whole layout:

if (window.onorientationchange) {
  window.onorientationchange = function() {
    var orientation = window.orientation;
    switch(orientation) {
      case 0:     // Portrait
          break;
      case 90:    // Landscape to the left
          break;
      case −90:   // Landscape to the right
          break;
    }
  }
}

Note:

Nokia N97 home screen widgets are just web documents that fire the onresize event when going from full screen to home screen mode and vice versa.

If the device isn’t an iPhone and supports onresize, we can detect the change using the following code:

if (window.onresize) {
   if (screen.width>screen.height) {
      // Landscape
   } else {
      // Portrait
   }
}

Table 28 lists the browsers’ compatibility with the onscroll and onresize events.

5.7. Key events

Key events—onkeypress, onkeyup, and onkeydown—allow us to detect keypresses over the whole page (body) or in one element (generally, a text input). On compatible mobile devices, this can be useful for many situations:

• To provide keyboard shortcuts

• To provide navigation or movement in a game or application

• To enable form submission on Enter or another keypress

• To disallow some characters in a text input

If we are going to prevent a key from being used, we should be very careful. Remember that devices can have very different keyboards. Some devices have only virtual keyboards, some numeric, and some QWERTY, and key code management across platforms can be a little tricky.

Table 29 shows the compatibility of key events over the body and in a text input.

Note:

If the device has a QWERTY keyboard we can also detect some modifier keys (if they exist), like Ctrl, Alt, or Shift, using the event properties.

A simple test for getting key codes can be created using the following code:

5.7.1. Useful keys for some devices

In Safari on iOS, while the focus is inside a text input with the keyboard visible onscreen, we can capture every key pressed using only keyCode. Table 30 shows some important codes.

There are Android and webOS (Palm) devices with physical keyboards, and others without them. The possible special key values for all these devices are shown in Table 31.

The Nokia N97 has a full QWERTY keyboard, but the letters don’t provide the correct ASCII values unless the user presses the Shift key at the same time. For example, the H and I keys provide the same keyCode (56) but different charCodes. The default Unicode values for the charCodes are the numeric or symbol values of the keys (typically used with the Sym key). If the user is using the onscreen keyboard (only available as a pop-up window when a form has focus), every character typed is delivered (regardless of whether it was entered on the numeric keyboard, by touch recognition, or by predictive text). Table 32 shows the common codes.

Warning:

Even if we can capture keypresses, remember that special keys (Menu, Call, End, Volume) are generally out of our scope as web developers. We cannot detect those keys.

Symbian 3^rd edition devices (including the Nokia N95, E61, and so on) are non-touch devices with numeric keypads. The few keys we can capture on such devices are shown in Table 33.

5.8. Preventing default behavior

For almost every event, we can prevent the default behavior by using the event.preventDefault method or capturing the event and returning false. This is commonly done with the onsubmit event, to cancel the submission when something doesn’t validate, or to cancel a link. For example:

<a href="news.html" onclick="news();return false">Go to news</a>

The preceding code is a standard link to news.html, but if JavaScript is supported we can capture the onclick event, call a local function (that can get the news by Ajax), and cancel the normal behavior of the link by returning false. This avoids a page load and reduces network traffic.

We can also prevent a key from being used by cancelling the onkeyup event. This feature must be used very, very carefully, and only on tested devices.

Table 34 shows which browsers support these three common scenarios.